Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add EIC projection measurements for polarised fits #266

Draft
wants to merge 30 commits into
base: master
Choose a base branch
from

Conversation

Radonirinaunimi
Copy link
Member

@Radonirinaunimi Radonirinaunimi commented Mar 11, 2024

@toonhasenack Here you find the kinematics for the projected measurements of various observables at the EIC. For each of these measurements, you have to implement the observable generator. There are two main classes of measurements:

EIC and EIcC:

These are projection measurements for $A_1^c \equiv g_1^c/F_1^c$ on electron-proton scattering. That is, the intermediate observables that we need to compute from Yadism are now g1_charm and F1_charm. In terms of computations, the pipeline (in your pineverse) is exactly the same as G1F1RATIO. In terms of dataset naming, we could call them <EIC/EIcC>_NC_<SQRTS>GEV_EP_G1F1CHARMRATIO where G1F1CHARMRATIO is again what you put in observable_name: G1F1CHARMRATIO later on in the data implementation.

The naming convention of the .txt files are as follow:

<EIC/EIcC>_<electron_beam_energy>_<proton_beam_energy>_A1C_<luminosity>fb-1.txt

where each column represent x, Q2, Asbolute_uncertainty.

Athena

These are projection measurements for $A_{LL} \equiv D(y) g_1/F_1$ on electron-proton scattering where

$$D=\frac{y(2-y)}{y^2 + 2(1-y)}$$

which depends on the inelasticity y is the depolarization factor. The computation of this observable is slightly more involved that what we've had to compute before. First, we need to compute the intermediate observable as before using g1 and F1, ❌ then compute the ratio between $g_1/F_1$ also as before by applying $1/F_1$ as k-factors. But now we also need to compute cfactor normalization by computing instead $D(y)$ rather than $1/(2x)$.

The corresponding datasets could be named: ATHENA_NC_<SQRTS>GEV_EP_ALL where again ALL is what you put in observable_name: ALL later on in the new commondata implementation. For this pseudo-measurement, the name of each column is given in the headers.

Important: There is only one single .xlsx file and given that there are different beam energies with overlapping $(x, Q^2)$ bins you need to separate them in terms of the center-of-mass energy - hence why the target grids are separated as follow.

PS: As you can see, the naming of the experiments are not fully consistent (given that Athena would be part of ePIC which is again part of EIC), if you have better name please suggest.

$\textcolor{red}{\rm NOTE}$: This was a mistake that shouldn't have happened, $1/(2xF_1)$ should be included as cfactor in the same way as $(1/(2x))$ and $D(y)$.

@alecandido
Copy link
Member

Important: There is only one single .xlsx file iven that there are different beam energies with overlapping

Converting it is not option? It could be CSV, JSON, YAML, or even .npy...

@Radonirinaunimi
Copy link
Member Author

Important: There is only one single .xlsx file iven that there are different beam energies with overlapping

Converting it is not option? It could be CSV, JSON, YAML, or even .npy...

Yes, these are definitely options indeed! Probably @toonhasenack should do that before parsing them in the obs generator, in this case it would be simpler.

@felixhekhorn felixhekhorn added enhancement New feature or request physics physics features labels Mar 11, 2024
@felixhekhorn
Copy link
Contributor

you don't want to base this on top of #232 ?

@Radonirinaunimi
Copy link
Member Author

you don't want to base this on top of #232 ?

I was not sure actually - the only tiny reason in basing it on top of master is that both don't have to be merged in order. But if you like it more on top of #232 I can change it.

@felixhekhorn
Copy link
Contributor

you don't want to base this on top of #232 ?

I was not sure actually - the only tiny reason in basing it on top of master is that both don't have to be merged in order. But if you like it more on top of #232 I can change it.

well, there you said your waiting for NNPDF, so surely here as well - and you may want to use dump_polarized also here ...

@Radonirinaunimi Radonirinaunimi changed the base branch from master to generators-pDIS March 11, 2024 14:33
@Radonirinaunimi
Copy link
Member Author

you don't want to base this on top of #232 ?

I was not sure actually - the only tiny reason in basing it on top of master is that both don't have to be merged in order. But if you like it more on top of #232 I can change it.

well, there you said your waiting for NNPDF, so surely here as well - and you may want to use dump_polarized also here ...

Branching off of #232 done. It was a bit dirty but that's now changed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a file extension here and to the others

Comment on lines +103 to +104
if "EIC" in target.parent.name or "EIcC" in target.parent.name:
heavyness = "charm"
Copy link
Contributor

@felixhekhorn felixhekhorn Apr 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again, better but not good enough yet 🙃 we can save these hard coded lines ... 1) we should always aim to avoid hardcoded stuff, as this will hinder the extensibility greatly 2) having this if here make the EIC implementation not self-contained, i.e. part of the logic is sitting here;

let me repeat what I said: "let's make heavyness an argument"; this means

  • change the signature of this function from dump_polarized(src_path, target) to dump_polarized(src_path, target, heavyness="total")
  • and then in the driver file you replace from blub.bla import dump by from blub.bla import dump as raw_dump [...] def dump(src_path, arget): return raw_dump(src, target, "charm")

Comment on lines +87 to +93
data = np.genfromtxt(src_path)

if (
"ATHENA" in target.parent.name
or "EIC" in target.parent.name
or "EIcC" in target.parent.name
):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same holds as for my comment on heavyness - let's drop these ifs to a "higher level", i.e. outside of this function into the caller; see my previous comment about the options (and the freedom you have) - if you insist on a switch here, you could do it by file type (but NOT by name) and don't change the default how data is read (because the new way is actually the minority)

@giacomomagni giacomomagni added datatoolchain observable card generator and removed physics physics features labels May 1, 2024
Base automatically changed from generators-pDIS to master July 12, 2024 11:03
@giacomomagni giacomomagni marked this pull request as draft August 23, 2024 12:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
datatoolchain observable card generator enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants